The present invention relates to Web Service policies, and more particularly, to federating policies from multiple policy providers.
Web services are self-contained pieces of programmatic logic that communicate externally through XML based messaging, typically in conformance with a SOAP protocol. Web services are often defined through languages such as WSDL and are registered within one or more registries, such as a Universal Description, Discovery, and Integration (UDDI) registry. Every Web service is associated with one or more policies, which can be defined as a set of assertions (rules, requirements, obligations) that define properties of a contract of a Web service based communication. Web service policies define an interface for the Web services (typically defined using WSDL in a UDDI directory), define a format of a message payloads of the Web service (typically defined using WSDL in a UDDI directory), and/or define other behavior requirements of the Web service. Some of the behavior requirements (policies) of Web service relate to ensuring an established Quality of Service (QoS), others relate to monitoring the Web service performance, others to security considerations for the Web service, still others relate to defining and enforcing business goals and/or logic.
Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. The terms “representational state transfer” and “REST” were introduced in 2000 in the doctoral dissertation of Roy Fielding, one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification. The terms have since come into widespread use in the networking community. REST strictly refers to a collection of network architecture principles which outline how resources are defined and addressed. The term is often used in a looser sense to describe any simple interface which transmits domain-specific data over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies.
Policy enforcement/access points exist in a runtime environment that are configured to support Web services. These enforcement or access points are nodes of a runtime environment which are configured to ascertain specifics of one or more Web service policies, to apply suitable programmatic logic to enforce the policy, and/or to enact a programmatic action based upon one or more defined policies.
A challenge with Web service policies is that there are often many different policy providing domains (security, routing, monitoring, etc.), and not all of these domains are centralized. For example, access control policies can be contained in an access manager, such as IBM TIVOLI ACCESS MANAGER. Routing policies can be defined within a registry repository, such as WEBSPHERE SERVICE REGISTRY AND REPOSITORY (WRSS). Monitoring policies can be contained in an application management component, such as IBM TIVOLI COMPOSITE APPLICATION MANAGEMENT (ITCAM). For an enforcement point and/or access point to be aware of all policies to be applied to a Web service, multiple policy providers must be queried.
Numerous efforts for establishing metadata repositories (e.g., WSRR, TIVOLI CHANGE AND CONFIGURATION MANAGEMENT DATABASE (CCMDB), TIVOLI FEDERATED IDENTITY MANAGER (TFIM), etc.) have been attempted and are in existence. While these efforts have each yielded beneficial results in many ways, none have resolved problems with effectively federating policies. One reason for this is that previous efforts for federating policies assume that there is a single point/location/registry where all policies are registered. Each currently existing policy provider (WSRR, CCMDB, TFIM, etc.), however, addresses numerous concerns relating to Web services in different ways, which to this point has prevented policies from being centrally registered. These specific concerns are important for the various components to perform their individual roles (i.e., security for TAM, monitoring for ITCAM, etc.).
It should be noted that the policy providers detailed above are all components of a common architecture or solution for Web services (e.g., are IBM-centric components). Other architectures exist, each having an architecture specific set of policy providers. Additionally, policies are currently defined by policy providers using numerous largely incompatible languages; some having an approach of defining policies as instances (e.g., Web Services Policy Language); others having an approach of expressing policies as classes (OWL-DL). In light of the above, no unification of Web service policies into a single “master” repository is expected in the near future, if ever. At the same time, no known solution exists for unifying or federating policy data from multiple policy providers.
FIG. 1 (prior art) illustrates a current situation regarding Web services and their policies. At present access/enforcement points 112 can receive services/resource 122 from a resource server 120. An access point 112 can consist of one or more users 114 interacting with a client 116 that utilizes the service/resource 122. An enforcement point 112 can include a software agent executing on a computing device (116) that utilizes the service/resource 122. Each of the resources/services 122 have a number of associated policies 126 stored in different data stores 128. Any entity/data store 128 that stores resource policies 126 can be generically referred to as a policy provider. The policy providers 128, resource server(s) 120, and access/enforcement points 112 can each be connected via a network 118. Resource servers 120, access points 112, policy enforcement points each have to query multiple different policy providers 128 to determine relevant policies 126 applicable to a given service/resource, which results in synchronization problems and inconsistent policy application as previously noted.